- HACKING UNIX - PART FOUR: Dealing with Firewalls ----------------------------------- Edit started on 05/06/02 (MM-DD-YY) Edit finished on 01/07/02 (MM-DD-YY) By: detach (XT) - [DuHo] & ** This is a multi-part tutorial, & ** please check our website for other & ** parts: & ** http://www.duho.org/ & INDEX: 0. - Forword 1. - Introduction 2. - Packet Filtering Firewalls 2.1 - A pracical Example 3. - How does the packet filter work 3.1 - Introduction 3.2 - Stateless or Stateful 4. - Dealing with Firewalls 4.1 - Introduction 4.2 - 2D mapping of a firewall ruleset 4.3 - 3D mapping of a firewall ruleset 5. - Using the gathered information 6. - Final words 0. Forword This part explains what firewalls are, their purpose and how they work. You will learn several techniques to detect a firewall and to discover it's ruleset later on in this part. Understanding firewalls requires understanding on networking and other things, certain references are included to obtain that knowledge. It's important to understand the role of firewalls in security and how they work. This will be described and later on I'll focus on common weaknesses. 1. - Introduction Users on an internal network may need to access other networks in an interconnected environment. An organisation may want to restrict access to the Internet and will especially want to restrict access from the untrusted Internet into the internal network. Firewalls are used to control network activity between the interconnected networks. Therefor an administrator creates a policy based on information about the services that users need to access on the external network and the services on the internal network requiring access from the outside of the network. It is also possible to restrict access into the internal network to a certain part of the external network and vise-versa. Using the policy, the ruleset is defined and applied to a firewall placed between the two networks. A firewall is only effective if users are forced to access the external network through the firewall (and vise-versa). When a computer on the internal network has a modem it may be possible to access the external network through a dial-up connection completely bypassing the policy. In this part you'll be introduced to the techniques hackers use to deal with firewalls. 2. Packet Filtering Firewalls In this chapter I discuss where and how firewalls are used. Chapter 3 generally explains how a firewall works and later on we'll focus on ``dealing with packet filters''. Packet filters have a ruleset defined by the administrator. The packet filter often operates at kernel-level and checks the header* on the packet to see where it's heading. It than looks for these targets in it's ruleset and decides it's fait. The packet can be discarded or accepted in different ways, or it may trigger another action (for example to accept the packet to pass through but to log the event). { A header is like an envelope that sets the receiver (and sender). On network-packets we have multiple envelopes (headers) that together form the exact destination (it is layered). } In the case of the internet most packet filters operate on IP and TCP level. IP specifies the host the packet is heading to, TCP identifies the program that the packet is destined for. 2.1 A practical example. We'll follow the proces the administrator of TotallySecure Inc. takes for defining a packet filtering ruleset. The first smart rule the administrator defines looks like this: Source: Anywhere Destination: Anywhere Protocol: Any Destination port: Any Policy: DENY The next thing the administrator does is to identify the exceptions to this base rule. { Note that there are also administrators that at first ACCEPT everything and then close some ports. This is the wrong way of thinking. Security can only be brought to the max. when you first disable everything and then enable some required features. And that goes for almost any element of a system. } An administrator may have a mailserver inside the organisations network. The mail is delivered from and to the mailserver through the SMTP service (for example sendmail or qmail). The administrator knows that the SMTP service must be reachable from the internet to be able to receive mail. So the administrator defines a new rule (exception on the first rule): Source: External (Internet) Destination: Internal mailhost Protocol: TCP Destination Port: 25 (SMTP) Policy: ACCEPT. Meaning that any packets from any address destined for the SMTP service (TCP port 25) on the mailhost will be forwarded to the appropriate direction. The administrator grants all systems on the internet to deliver e-mail to users' mailboxes. He does not have to define a rule for the internal network. The users just need to connect to the mailserver, not to a mailserver outside the internal network, so he'll only need to make an exception for SMTP from the mailhost: Source: Internal mailhost Destination: External (Internet) Protocol: TCP Port: 25 Policy: ACCEPT. The next thing the administrator wants is to allow users to receive their mail from their mailbox on the mailserver using the POP3 protocol. The administrator prefers to DENY access to the POP3 service from the internet side. He asks several users if they *have to* retrieve their mail from anywhere outside the organisation and finds out it's safe to block access to this server from the internet-side for POP3 access. He knows he won't need to change the firewall rules as this is no exception to the first rule, although he just adds it to his note for reference: Source: External Destination: Internal Protocol: TCP Destination Port: 110 (POP3) Policy: DENY. The administrator realises the simple fact that users need to use HTTP access to the internet. He can simply ACCEPT outgoing HTTP traffic or further restrict this access using a proxy server (in the last case he only needs to allow outgoing HTTP from the proxy server). He decides the last method is more secure. He installs a HTTP/HTTPS/FTP proxy all-in-one solution. The proxy server runs on port 8080 and needs only to be accessed from the internal network. So incoming traffic to port 8080 can safely be blocked. He sets up a LAN for the users behind the proxy server. He adds a second network card to the mailserver so that the mailserver is accessible on the LAN aswell as from the internet. The first rule he adds is to allow outgoing FTP/HTTP/HTTPS from the proxyserver: Source: Internal proxy-server Destination: External Protocol: TCP Destination Port: 21 (FTP), 80 (HTTP), 443 (HTTPS) Policy: ACCEPT. The administrator has now defined all rules he thinks are necessary. Next the administrator goes on with adding spam- and virusblocking to his mailserver etcetera. 3. How does the packet filter work. 3.1 Introduction Network packets come into the network card which are then received at the kernel of the operating system. If the operating system is setup as a router it reads the packet and knows where to send the packet to. When a firewall is installed it has the ability to read the packets and the possibility to do something with it. It can drop (discard) the packet, refuse (block, reject) the packet, accept the packet for further processing or manipulate (mangle) the packet. All these decisions are based on the information in the protocol's header which are matched against filter rules. I haven't explained the difference between dropping a packet and refusing (blocking) a packet. A dropped packet is simply thrown away (discarded) and the sender of that packet receives no notice. Rejecting (refusing) a packet means discarding the packet and replying with a TCP RST packet, the same response as it gets when you would try to open a connection to a non-existing port. Ofcourse this rejecting only takes place when there are specific flags set. To fully understand this you should read RFC 793 (TCP) and RFC 791 (IP). 3.2 Stateless or Stateful. A stateless firewall is very basic, it may simply check destination and source address, destination port and source port and decide what to do with it. A stateful packet filter keeps track of a connection and has the ability to do some meaningful packet manipulation. For example Network Address Translation (NAT), where protocol information can be changed before it is forwarded. This is used for example to make an internal host (with a private-range IP-address) addressable from the internet. Stateful packet filters can also have protocol helpers, which can be used to make a protocol work through a firewall by manipulating the application-level-data that the packet contains or anything more creative. 4. Dealing with Firewalls. 4.1 Introduction Firewalls itself are not a target for our attacks. This may sound obvious but this is exactly what is suggested when saying ``how can I break security?'' or more explicitly ``how can I break through a firewall''. It is not about breaking security it is about taking advantage of insecurity elsewhere. More intelligent people do know this but still talk about 'breaking security' which is plain wrong. That's why I called this part "Dealing with Firewalls" and not "Breaking Firewalls". Although, there have been occasions where the firewall software itself introduced new vulnerabilities. And some (older) firewalls may simply not work well, but you'll see that. At first we will concentrate on a different way to get around firewall restrictions anyway. So we are going to *deal* with the firewalls and we will find out a different way to defeat or bypass them. 4.2 2D discovery of a firewall ruleset In this paragraph I will explain some techniques useful to map a firewalls ruleset. This information is very useful for later stages of attack. For example, you will already know how your backdoor needs to be configured, or what kind of backdoor you will need. You may also need the information for some kid of attacks on systems behind the firewall. We are not going to focus on compromising the firewall initially because it is probably secure enough, however, if it is vulnerable to remote attack we'll find out anyway. Now we are going to watch over the shoulder of a hacker named John that is about to map the firewall ruleset of TotallySecure Inc's firewall. John has just surfed into the website of TotallySecure and wants to know if the company deserves the name it has. Note that this stage should be part of the information gathering stage discussed in part 2. John first sends a harmless ping addressed to the webserver: # ping www.totallysecure.org PING www.totallysecure.org (123.123.123.123): 56 octets data --- www.totallysecure.org ping statistics --- 12 packets transmitted, 0 packets received, 100% packet loss # John knows there must be a some device in the way that drops the ICMP (ping) ECHO REQUEST packets, although he knows it doesn't have to be the webserver itself. Next, John wants to know if some ports are also being filtered (dropping incoming connections on certain ports). Administrators often rather filter ports and protocols instead of blocking them because the host appears to be offline. With the knowledge that a closed port needs to respond with an RST/ACK packet when sending a SYN packet to it, he could see if the firewall is filtering ports. He'll use the program 'hping' to discover this (found at http://www.hping.org/): # hping www.totallysecure.org -S -p 85 HPING www.totallysecure.org (eth0 123.123.123.123): S set, 40 headers + 0 data bytes --- www.totallysecure.org hping statistic --- 10 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms # The -S switch indicates the SYN flag to be set and the -p flag specifies the destination port. No response at all, it must be filtered too. Now, if this firewall is intelligent in anyway, it will also drop any loose ACK packets to that port. The normal behavior when sending a lonesome ACK packet to a port is to receive an RST response. Now if the firewall is not that smart it may only block SYN (for connection synchronization) packets to that port. If we receive an RST packet after sending an ACK packet to port 85 it indicates that it's a very basic firewall. # hping www.totallysecure.org -A -p 85 HPING www.totallysecure.org (eth0 123.123.123.123): A set, 40 headers + 0 data bytes --- www.totallysecure.org hping statistic --- 4 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms # No response at all, okay it's probably filtered properly. Note that the ACK packets send to unfiltered ports (whether open or closed) always return an RST packet. You can not determine if a port is open or closed. Now, it is not important which port we used for this action (85), aslong as we think it is probably not in use. It is this clue that may make us think that the host has filtered all ports and made exceptions to specific ports that require to be open (like the webserver). Atleast we may conclude that because it is very unlikely port 85 is in use, as no well-known service has this port assigned as yet. How do I know this? # grep 85 /etc/services # So if the admin is filtering a port that isn't in use, why wouldn't he filter all ports that aren't in use? So John may assume now that the administrators first rule was to DROP any connection on incoming ports, atleast from the outside (the Internet). No ordinary backdoor could be installed on the firewall without changing the ruleset if the firewall works properly. Knowing that this packet filter also filters ACK packets, we can later on scan all ports with ACK packets to make sure everything is filtered. There is another a way to see if the firewall is filtering properly, this is done by testing it with fragmented packets. Fragmented packets are normally used to send packets over networks with a low Maximum Transmission Unit (MTU). Fragments can be this small that even the header is split up into multiple packets. Some firewalls fail at blocking such packets as they don't have the complete header, and they don't wait to collect all fragments for reconstruction. John performs a simple test against www.totallysecure.org with Fyodor's Nmap tool: # nmap -sS -p85 -f www.totallysecure.org -P0 Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on www.totallysecure.org (123.123.123.123): Port State Service 85/tcp filtered unknown Nmap run completed -- 1 IP address (1 host up) scanned in 36 seconds # He uses the -f switch to fragment the packet, -P0 to tell Nmap not to check if the host is up (as PINGs don't pass through, Nmap will otherwise think the host is down), -sS to do a SYN scan. As it turned out, Nmap split the packet in 6 fragments, as seen with a header sniffer. We could do this scan with ACK packets as well. What if we send packets with no flags at all? A so-called NULL scan should return RST packets if the port is closed, and no result if the port is open. It is this why this scan is not really reliable, because this type of scan indicates a port being open if it is filtered (dropped). The problem is that Windows systems return an RST packet even if the port is open (against the specification) and so this scan is not usable to scan Windows systems. But it is still useful against Windows systems for testing the firewall ruleset, the same way as using ACK packets. For UNIX systems it is useful if we have to deal with a basic firewall that only blocks SYN packets. Because then we already know what port the firewall is supposed to filter. Then we use a ACK scan to determine if the firewall is a basic one. Then we use the NULL scan to see if the port being filtered is actually open or not. For example: Step 1: # nmap -sS -p110 www.totallysecure.org -P0 Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on www.totallysecure.org (123.123.123.123): Port State Service 110/tcp filtered pop3 Nmap run completed -- 1 IP address (1 host up) scanned in 1 second # Step 2: # nmap -sA -p110 www.totallysecure.org -P0 Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) The 1 scanned port on www.totallysecure.org (123.123.123.123) is: UNfiltered Nmap run completed -- 1 IP address (1 host up) scanned in 1 second # Step 3: # nmap -sN -p80 www.totallysecure.org -P0 Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on www.totallysecure.org (123.123.123.123): Port State Service 110/tcp open pop3 Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds # See, in case the admin used a basic packetfilter, we just found out the POP3 service is open but filtered. If that didn't succeed, we should also try in conjunction with the fragmentation option (-f). This knowledge may introduce the idea that the port must somehow be in use, maybe only to serve internal netwerk users. Otherwise the administrators is to lazy to turn off the POP3 service. Using the above techniques, John has a basic idea of the type of firewall being used. In this case John concludes www.totallysecure.org is secured by one or more firewalls that drop incoming connections on filtered ports. The firewall is not vulnerable to fragmented packets nor is it a basic firewall that chases after SYN packets only. John continues finishing his 2D view of the webserver by doing the SYN, ACK and NULL scans against all the 65535 possible ports during the period of about month (not not raise too much suspicion). The 2D map results in: Protocol ICMP: dropped All TCP ports dropped except port 80. John has both gathered information on the open/closed ports and the firewall configuration. He did it in a non-intrusive and stealthy manner. The next questions John wants to investigate are: - is the firewall on the same site as the webserver? - howmany firewalls are there? - where are the firewalls located? This is what I call a 3D mapping. A 2D mapping maps all obstacles in the way to a target, no knowledge of distance are known. In a 3D map John knows on which systems services are available and where packets are filtered. 4.3 3D mapping of a firewall ruleset What I call -3D mappings- are a series of probes and information gathering methods that result a visual map. It is used to determine which sites provide which services while figuring out why it is setup that way along with the location of where packets are filtered. Combining this information with the 2D mapping results a detailed report of the physical configuration as well the logical configuration and why it works that way. Again, we'll follow John the hacker in his info gathering stage with TotallySecure Inc. being his target. In the 2D mapping stage John learned that (probably all) ICMP type packets don't pass through. In this stage John wants to know which device along the way is blocking it. Now how does he do that? He's about to use a series of traceroute-type probes to determine the site that's blocking these packets. First things firts, John writes a quick shell script for determining the location of the ICMP filter: --- trace_icmp.sh --- #!/bin/sh # determine ICMP filter location cnt=1 while [ $1 ] ; do echo hop \#$cnt: hping -1 -c 1 -t $cnt $1 let cnt=cnt+1 sleep 1 done --- end --- John is now able to determine where the packet is filtered. --- determine ip address --- # nslookup www.totallysecure.org Server: 127.0.0.1 Address: 127.0.0.1#53 Name: www.totallysecure.org Address: 123.123.123.123 # --- end --- John first looks up the ip adress so hping won't have to look it up itself everytime. --- trace icmp filter --- bash-2.05a# ./trace_icmp.sh 123.123.123.123 hop #1: HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes TTL 0 during transit from ip=100.100.100.1 name=gateway.attackers.org --- 123.123.123.123 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms hop #2: HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes TTL 0 during transit from ip=100.100.1.1 name=gateway.hackerisp.org --- 123.123.123.123 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms .... .... .... .... hop #18: HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes --- 123.123.123.123 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms hop #19: HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes ICMP Packet filtered from ip=123.123.1.1 name=UNKNOWN --- end --- Now this makes sense, the filter that filtered the ping packets was not the one on the webserver... but a gateway at hop #19. Next John wants to know on which hop the webserver is. How does he figure that out? Simple: --- trace_tcp.sh --- #!/bin/sh cnt=1 while [ $1 ] ; do echo hop \#$cnt: hping -S -p $2 -c 1 -t $cnt $1 let cnt=cnt+1 sleep 1 done --- end --- How could you use this script? Well, just pick a port that you know is open, John will use port 80. Then this script can be used to determine the number of hops until the port 80 has been reached. Let's see John in the act: --- trace count hops to destination --- bash-2.05a# ./trace_tcp.sh 123.123.123.123 80 hop #1: HPING 123.123.123.123 (eth0 123.123.123.123): S set, 40 headers + 0 data bytes TTL 0 during transit from ip=100.100.100.1 --- 123.123.123.123 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms .... .... .... .... hop #21: HPING 123.123.123.123 (eth0 123.123.123.123): S set, 40 headers + 0 data bytes len=46 ip=123.123.123.123 flags=SA DF seq=0 ttl=63 id=0 win=5840 rtt=575.6 ms --- end --- John learned that there is a packet filter filtering ICMP packets at hop 19, and the webserver is at hop 21. That's interesting, so the second gateway from the webserver is filtering ICMP packets. It may also be possible that the first gateway before the webserver is also filtering ICMP, but that doesn't matter. Next John wants to know if all ports are firewalled by that firewall. So he does another probe: --- # hping -A -p 85 -c 1 -t 19 www.totallysecure.org HPING www.totallysecure.org (eth0 123.123.123.123): A set, 40 headers + 0 data bytes TTL 0 during transit from ip=123.123.123.1 name=UNKNOWN --- www.totallysecure.org hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms # --- end --- Nope, we receive an ICMP port unreachable atleast port 85 is not filtered at the same address as ICMP is filtered. Now there are only two options: the packet is filtered at the gateway just before the webserver, or on the webserver itself: --- determining where port 85 is filtered --- # hping -A -p 85 -c 1 -t 20 www.totallysecure.org HPING www.totallysecure.org (eth0 123.123.123.123): A set, 40 headers + 0 data bytes --- www.totallysecure.org hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms # --- end --- Port 85 is filtered at the gateway before the webserver. Let's see which address this gateway has: --- resolving gateway address --- # hping -S -p 80 -c 1 -t 20 www.totallysecure.org HPING www.totallysecure.org (eth0 123.123.123.123): S set, 40 headers + 0 data bytes TTL 0 during transit from ip=123.123.123.1 name=UNKNOWN --- www.totallysecure.org hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms # --- end --- As we already knew, it is 123.123.123.1 that is firewalling this port. John continues his probing work and finds out the following: 123.123.1.1 (hop 19) filters: ICMP, TCP port 31337 123.123.123.1 (hop 20) filters: All TCP ports except port 80 John considers that TotallySecure Inc. owns the whole 123.123.123.0 segment, and that 123.123.123.1 is their own firewall. 123.123.1.1 is probably the gateway of their ISP (Internet Service Provider). John draws the following 3D map: ******************* # 123.123.123.123 # ******************* _________|_____________|_____________|_____________|_____________|__ | ***************** # 123.123.123.1 # ***************** ___________|_____________|_____________|_____________|______________ | *************** # 123.123.1.1 # *************** | *** *** *** **** INTERNET **** *** *** *** John believes that TotallySecure Inc.'s network must have a mailserver that's in the 123.123.123.0 segment. So how could he verify this? Simple: --- lookup mailserver --- # host -t mx totallysecure.org totallysecure.org mail is handled by 100 relay1.bizznet.com. totallysecure.org mail is handled by 50 mail.totallysecure.org. # --- end --- Aha, two mail handlers, one appears to be the one of the ISP, and one probably operated by totallysecure themselves. # host relay1.bizznet.com relay1.bizznet.com has address 123.123.1.65 # host mail.totallysecure.org mail.totallysecure has address 123.123.123.80 # John draws the new 3D map: ******************* ****************** # 123.123.123.123 # # 123.123.123.80 # ******************* ****************** _________|_____________|_____________|_____________|_____________|__ | ***************** **************** # 123.123.123.1 # # 123.123.1.65 # ***************** **************** ___________|_____________|_____________|_____________|______________ | *************** # 123.123.1.1 # *************** | *** *** *** **** INTERNET **** *** *** *** The firewall only passes port 80 traffic if the destination is the webserver, and port 25 only if the destination is the mailserver. Very smart! John continues to fill in the above geographical map with this information and the gathered information from the 2D mapping. Note that the 3D mapping thing includes a technique called 'Firewalking' discovered by Mike D. Schiffman and David E. Goldsmith. They also wrote a program called 'Firewalk' to bring this technique to the public. You can more information on it here: http://www.packetfactory.net/Projects/firewalk/ John continues to scan all 255 possible hosts behind the firewall, but comes up with no new results. 5. Using the gathered information John knows that this packet filter is set up fairly restricted: - John sees no possibity to compromise the firewall itself - John can't use no classic inbound backdoor when exploiting weaknesses in a system behind the firewall - No ICMP channel available In later stages when John is able to compromise one of the servers behind the firewall (either through active attack on the mailserver or attack on the webserver), he won't be able to use a classical inbound backdoor. To play it safe, John needs to trojan or patch either the mailserver software or the webserver. Another way is to use a reversely connecting backdoor, that connects to a local server on your system instead of the reverse. But that would not be very smart, as the backdoor would require to know the address of his attacking host, also outgoing traffic may be restricted too. A backdoor on the webserver could be a server-side script that can execute things through a webinterface. Or a special module, or a real patch of the webserver which can be controlled through specially crafted requests. Otherwise, the mailserver needs to be patched. He could also create an automated program which works like a worm that compromises the whole network behind the firewall and leaks information back to John, which would require John to guess what vulnerabilities could be exploited behind the firewall. 6. Final words In this part you learned how to gain important information about the target's network set-up as well as understanding how packet filters are configured and how they sometimes can be bypassed. These methods should be part of the information gathering stage discussed in part 2, though there was somuch to tell that it deserves a seperate part. Please look out for new 'Hacking Unix' parts during the next couple of months. detach (XT) [DuHo] 2002 Visit http://www.duho.org/ for updates or new parts of this tutorial every now and then. -EOF- Size: 32768 bytes chars: 29428 words: 4556 Lines: 767